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EXAMINER'S ANSWER 

This is in response to the appeal brief filed 06/10/2008 appealing from the Office 
action mailed 01/02/2008. 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in 
the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or 
judicial proceedings which will directly affect or be directly affected by or have a 
bearing on the Board's decision in the pending appeal. 

(3) Status of Claims 

The amendment after final on 02/28/2008 which was initially not entered 
into record by the examiner, contains an amendment to claims 2-6, 8-10, 12-16, 
18-20, and 22-24 which is reflected on claims presented in this appeal brief filed 
on 06/10/2008. The examiner now enters the amendment to claims 2-6, 8-10, 
12-16, 18-20, and 22-24 to reduce the issues of appeal, and this amendment 
should be entered into record. The statement of the status of claims in the brief 
is correct. 

(4) Status of Amendments After Final 

There are amendments after final (filed 02/28/2008) which were initially 
not entered into record by the examiner, but now are being entered into record to 
reduce the issues for appeal. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on 
appeal is correct. 

(7) Claims Appendix 
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The copy of the appealed claims contained in the Appendix to the brief is 
substantially correct. An after-final amendment filed on 02/28/2008 to claims 2-6, 
8-10, 12-16, 18-20, and 22-24 that was initially not entered into record, is now 
being entered by the examiner to reduce the issues for appeal. The amendment 
should be entered to claims 2-6, 8-10, 12-16, 18-20, and 22-24. 

(8) Evidence Relied Upon 

2002/0178103 Danetal. 11/28/2002 

2003/0167446 Thomas 09/04/2003 

2002/0042657 Albazz et al . 04/1 1 /2002 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claim Rejections - 35 USC § 103 

5. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 1 02 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

6. This application currently names joint inventors. In considering 
patentability of the claims under 35 U.S.C. 103(a), the examiner presumes that 
the subject matter of the various claims was commonly owned at the time any 
inventions covered therein were made absent any evidence to the contrary. 
Applicant is advised of the obligation under 37 CFR 1 .56 to point out the inventor 
and invention dates of each claim that was not commonly owned at the time a 
later invention was made in order for the examiner to consider the applicability of 
35 U.S.C. 103(c) and potential 35 U.S.C. 102(e), (f) or (g) prior art under 35 
U.S.C. 103(a). 

7. Claims 1-6, 8-16, and 18-24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Dan et al. (U.S. PGPUB 2002/0178103), in view of Thomas 
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(U.S. PGPUB 2003/01 67446), and in view of Albazz et al. (U.S. PGPUB 
2002/0042757). 

8. Regarding claims 1 and 11, Dan teaches a method and a program storage 
device comprising: 

A) establishing an original pre-defined data type definition format for an XML 
transaction (Paragraphs 31 , 50, & 58, Figures 8-9); 

C) pre-building static structures of said XML transaction (Paragraphs 33-35); 
E) classifying dynamic structures of said XML transaction with empty tags and 
single occurrence classifiers for repeating dynamic structures (Paragraphs 34- 
35); 

I) wherein an occurrence of said runtime of said XML transaction occurs when 
said XML transaction occurs when said XML transaction is sent to a trading 
partner (Paragraphs 33-34, 36); 

J) wherein said combining comprises filling the empty tags of said dynamic 
structures (Paragraphs 34-35); and 

K) constructing a final XML structure based on the combining process 
(Paragraph 46); 

L) wherein said final XML structure comprises fully built dynamic structures that 
comprise completely filled tags (Paragraphs 34-35, 46). 

The examiner notes that Dan teaches "establishing an original pre- 
defined data type definition format for an XML transaction" as "According to 
the invention, a meta-contract governs or controls the negotiation process. The 
meta contract is either pre-negotiated or formed from information provided by the 
parties in one or more electronic documents, preferably in the form of profiles, 
described in greater detail below... Before creating a meta-contract, the parties 
must first accept a negotiation protocol to be used during the negotiation 
process. After the parties accept the negotiation protocol, a meta-contract may 
be formed and the parties may begin a negotiation" (Paragraph 31), "FIG. 8 
illustrates the preferred data type definition (DTD) covering all offer documents" 
(Paragraph 50), and "FIG. 9 illustrates the preferred data type definition (DTD) 
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covering all counter offer documents" (Paragraph 58). The examiner further 
notes that Dan teaches "pre-building static structures of said XML 
transaction" as "The profile serves as the starting point of a negotiation by 
providing an initial version of a contract document" (Paragraph 33), "The profile 
may be expressed, for example, as an XML document whose contents may be 
incorporated into a contract" (Paragraph 34), and "One example of a contract 
template is an almost-complete electronic contract document with a few fields left 
blank" (Paragraph 34). The examiner further notes that Dan teaches 
"classifying dynamic structures of said XML transaction with empty tags 
and single occurrence classifiers for repeating dynamic structures" as "a 
negotiable field 1023 or 1024 may be treated as a blank that me be completed by 
the negotiating party" (Paragraph 35). The examiner further notes that Dan 
teaches "wherein an occurrence of said runtime of said XML transaction 
occurs when said XML transaction occurs when said XML transaction is 
sent to a trading partner" as "The profile serves as the starting point of a 
negotiation by providing an initial version of a contract document" (Paragraph 
33), "The profile may be expressed, for example, as an XML document whose 
contents may be incorporated into a contract" (Paragraph 34), and "One example 
of a contract template is an almost-complete electronic contract document with a 
few fields left blank" (Paragraph 34). The examiner further wishes to state that 
the initial contract must combine the static fields (almost complete portions) and 
dynamic fields (the blank portions) at runtime (when the contract is sent to other 
party). The examiner further notes that Dan teaches "wherein said combining 
comprises filling the empty tags of said dynamic structures" as "a 
negotiable field 1023 or 1024 may be treated as a blank that me be completed by 
the negotiating party" (Paragraph 35) The examiner further notes that Dan 
teaches "constructing a final XML structure based on the combining 
process" as "the negotiation continues 370 to step 380 where the negotiation is 
complete and step 390 leads to the service contract or TPA" (Paragraph 46). 
The examiner further notes that Dan teaches "wherein said final XML 
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structure comprises fully built dynamic structures that comprise 
completely filled tags" as "the negotiation continues 370 to step 380 where the 
negotiation is complete and step 390 leads to the service contract or TPA" 
(Paragraph 46). 

Dan does not explicitly teach: 
B) creating a copy of said original pre-defined data type definition format for said 
XML transaction; and 

M) wherein said final XML structure is validated by comparing said final XML 
structure against said copy of said original pre-defined data type definition format 
for said XML transaction. 

Thomas, however, teaches "creating a copy of said original pre- 
defined data type definition format for said XML transaction" as "the 
processor reads 12 the document type definition (DTD) of the first XML file and 
creates a copy 13 of the DTD" (Paragraph 38) and "wherein said final XML 
structure is validated by comparing said final XML structure against said 
copy of said original pre-defined data type definition format for said XML 
transaction" as "Once the user has finished entering modifications to the XML 
file and all of the modifications have been found to be either not significant or 
valid semantic changes, the temporary version of the XML file in the RAM 7 is 
written over the original XML file in the first storage region 4" (Paragraph 44). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of the cited references because 
teaching Thomas's would have allowed Dan's to provide a method to record 
changes to a markup language file by validating them in order to allow that file to 
be in compliance with constraints defined in a set of declarations, as noted by 
Thomas (Paragraph 5). 

Dan and Thomas do not explicitly teach: 
D) wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type and a predetermined trading partner 
profile; 
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F) building a list of a sequence of said static and dynamic structures; 

G) linking said list to the XML transaction and said predetermined trading partner 
profile; 

H) combining said static structures with said dynamic structures at a runtime to 
construct said XML transaction based on said sequence, said type of XML 
transaction, said trading partner profile, and said dynamic structures of said XML 
transaction. 

Albazz, however, teaches "wherein said static structures comprise a 
pre-built XML data structure with pre-fiiled values based on a transaction 
type and a predetermined trading partner profile" as "the preferred 
embodiment of the invention provides for the creation of many different Ts&Cs 
Sets using the Business Rules Book. Each Ts&Cs Set represents an integrated 
set of terms and conditions which can be used selectively by the sales group to 
prepare and propose contracts to prospective buyer organizations. In a 
marketplace, different Ts&Cs Sets created by a supplier can be used by the e- 
commerce site to respond to a request for quotation (RFQ) from a buyer either by 
automatic rating and matching of the request or by pre-assigning a Ts&Cs Set to 
the buyer" (Paragraph 55) and "During the contract negotiation process the seller 
may decide to switch into a more attractive Ts&Cs Set, to overcome buyer 
reluctance or a competitive offer and win the buyer's business. This is readily 
done by simply referencing a different Ts&Cs Set identifier or reference number 
in the proposed contract or in response to an RFQ. Once a contract is approved 
and signed by the buyer, a copy of the selected Ts&Cs Set becomes an integral 
part of that contract. A contract may only include one Ts&Cs Set" (Paragraph 
68), "building a list of a sequence of said static and dynamic structures" as 
"Product List Filter (PLF) is a representation of a seller's product list which 
replaces the complete list of all products available from a seller organization (as 
used herein the term "products" includes both products and services). This 
representation comprises products selection and/or exclusion criteria, based on a 
selection metaphor. The representation criteria are structured and stored in a 
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way that ensures rebuilding the targeted product list from a master product 
catalog, or from multiple catalogs or other product information sources, any time 
the target product list is required. Depending upon the used PLF, a generated list 
could be static with the same products being produced at every run, or could be 
dynamic with new products being added or removed according to changes taking 
place at the seller organization. FIG. 5 illustrates an example of the creation and 
storage of a Product List Filter" (Paragraph 76), "linking said list to the XML 
transaction and said predetermined trading partner profile" as "PLFs can be 
implemented within the contract preparation and negotiation cycles in different 
scenarios. For example, a seller may define a product list to be offered to a 
particular buyer and create a specific PLF for that list" (Paragraph 79), and "seller 
can define one or more PLFs that can be linked to offered Ts&Cs Sets or 
restricted to certain buyers, thus controlling the content of the product list on a 
buyer-specific basis. The specified buyer(s) become a target buyer for the filtered 
product list, and PLFs enforce the products viewable by any particular buyer in 
the execution aspect of the invention, discussed below, whenever the buyer 
accesses the seller's e-commerce site (store or marketplace). The buyer can 
then select or search for required products from the filtered version of the seller's 
master product list" (Paragraph 80), and "combining said static structures 
with said dynamic structures at a runtime to construct said XML 
transaction based on said sequence, said type of XML transaction, said 
trading partner profile, and said dynamic structures of said XML 
transaction" as "All contract Static Elements and Dynamic Elements are tied 
together in a contract profile, which includes linking the Product List Filter(s) and 
any Dynamic Elements in the Terms and Conditions Set. FIG. 6 illustrates an 
example of linking a Ts&Cs Page having a multiple Folds to a multiple-tier PLF. 
Other scenarios might involve linking Ts&Cs Page Folds to other contract 
elements, for example to different divisions of a buyer organization" (Paragraph 
81). 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of the cited references because 
teaching Albazz's would have allowed Dan's and Thomas's to provide a 
method to increase the flexibility of contract negotiation through the removal of 
rigid pre-defined terms and subsequent replacement of dynamic best-fit terms, as 
noted by Albazz (Paragraph 12). 

Regarding claims 2 and 12, Dan further teaches a method and program 
storage device comprising: 

A) wherein said XML transaction occurs in a business-to-business (B2B) 
electronic environment (Paragraph 29). 

The examiner notes that Dan teaches "wherein said XML transaction 
occurs in a business-to-business (B2B) electronic environment" as "method 
of automated negotiations of the invention is capable of producing a contract 
such as, for example, a service contract, and preferable a business-to-business 
(B-B) service contract" (Paragraph 29). 

Regarding claims 3 and 13, Dan further teaches a method and program 
storage device comprising: 

A) predefining said trading partner profile associated with a predetermined 
trading entity (Paragraph 38). 

The examiner notes that Dan teaches "predefining said trading partner 
profile associated with a predetermined trading entity" as "when each of the 
parties has a preexisting profile, an initial version of a contract may be created by 
automatically combining information from the profiles, subject to a later 
negotiation process" (Paragraph 38). 

Regarding claims 4 and 14, Dan further teaches a method and program 
storage device comprising: 
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A) wherein said pre-building of said static structures occurs prior to runtime of 
said XML transaction (Paragraphs 33-34). 

The examiner notes that Dan teaches "wherein said pre-building of 
said static structures occurs prior to runtime of said XML transaction" as 

"The profile serves as the starting point of a negotiation by providing an initial 
version of a contract document" (Paragraph 33), "The profile may be expressed, 
for example, as an XML document whose contents may be incorporated into a 
contract" (Paragraph 34), and "One example of a contract template is an almost- 
complete electronic contract document with a few fields left blank" (Paragraph 
34). The examiner further notes that contract of Dan's runs once the negotiation 
phase begins to fill in the initial blank negotiable fields 1023 and 1024. 

Regarding claims 5 and 15, Dan does not explicitly teach a method and 
program storage device comprising: 

A) wherein the construction of said final XML structure follows definition 
established by said copy of said original pre-defined data type definition format 
for said XML transaction. 

Thomas, however teaches "wherein the construction of said final 
XML structure follows definition established by said copy of said original 
pre-defined data type definition format for said XML transaction" as "The 
XML file is read and a temporary copy made and stored 28 in the RAM 7. The 
temporary copy of the contents of the XML file is displayed 29 by means of the 
output interface 10 so that a user is able to input modifications to the XML file via 
the input interface 9... Once the user has finished entering modifications to the 
XML file and all of the modifications have been found to be either not significant 
or valid semantic changes, the temporary version of the XML file in the RAM 7 is 
written over the original XML file in the first storage region 4. Of course, the 
modified version of the XML file may be stored separately from the original 
version of the XML file instead of overwriting the original XML version" 
(Paragraphs 43-44). 
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It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of the cited references because 
teaching Thomas's would have allowed Dan's to provide a method to record 
changes to a markup language file by validating them in order to allow that file to 
be in compliance with constraints defined in a set of declarations, as noted by 
Thomas (Paragraph 5). 

Regarding claims 6 and 16, Dan further teaches a method and program 
storage device comprising: 

A) filling said empty tags of said dynamic structures with business data values 
(Paragraphs 34-35); and 

B) building multiple repeating dynamic structures at runtime of said XML 
transaction (Paragraphs 34-35, 44). 

The examiner notes that Dan teaches "filling said empty tags of said 
dynamic structures with business data values" as "a negotiable field 1023 or 
1024 may be treated as a blank that may be completed by the negotiating party" 
(Paragraph 35) and "building multiple repeating dynamic structures at 
runtime of said XML transaction" as "A negotiation comprises one or more sub 
negotiations. Each sub negotiation involves a subset of all of the items to be 
negotiated" (Paragraph 44). 

Regarding claims 8 and 18, Dan further teaches a method and program 
storage device comprising: 

A) wherein said trading partner profile comprises partner data, communication 
protocol data, transaction data, transaction format data, and XML format version 
data (Paragraphs 33-35, Figure 4). 

The examiner notes that Dan teaches "wherein said trading partner 
profile comprises partner data, communication protocol data, transaction 
data, transaction format data, and XML format version data" as "The profile 
may include information such as: products and services provided, specific 
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business processes that the service provider can perform, security requirements, 
and technology information such as which message-exchange protocols are 
supported by the service provider" (Paragraph 33) and "Allowable choices 1014 
may cover, for example, business and/or technical considerations such as a list 
of supported transport protocols, a list of supported shipping and transport 
services (such as overnight shipping, airmail delivery, etc.), delivery times, and/or 
the optional use of preexisting meta contract" (Paragraph 35). 

Regarding claims 9 and 19, Dan further teaches a method and program 
storage device comprising: 

A) wherein said pre-building of said static structures and a pre-building of said 
dynamic structures occurs at a time of installation of said trading partner profile in 
a database in said computer system (Paragraph 10). 

The examiner notes that Dan teaches "wherein said pre-building of 
said static structures and a pre-building of said dynamic structures occurs 
at a time of installation of said trading partner profile in a database in said 
computer system" as "providing a starting state for a contract, wherein the 
starting state may be a previous contract, a publicly defined template such as, for 
example, Open Buying on the Internet (OBI), or a template defined prior to the 
negotiation by one of the parties" (Paragraph 10). 

Regarding claims 10 and 20, Dan further teaches a method and program 
storage device comprising: 

A) linking said static structures to a type of XML transaction and said 
predetermined trading partner profile (Paragraphs 32-34); and 

B) storing the linked static structures in said database (Paragraph 37). 

The examiner notes that Dan teaches "linking said static structures to 
a type of XML transaction and said predetermined trading partner profile" 
as "Starting definitions and values for these types of information in the negotiated 
contract may be provided in a TPA template or party profile" (Paragraph 32) and 
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"storing the linked static structures in said database" as "In a preferred 
embodiment of the invention, an initial version of a contract may be obtained 
from a repository that contains a collection of searchable information, including 
individual businesses' contract templates or profiles and other related 
information" (Paragraph 37). 

Regarding claim 21 , Dan teaches a computer system comprising: 
A) means for establishing an original pre-defined data type definition format for 
an XML transaction (Paragraphs 31 , 50, & 58, Figures 8-9); 
C) means for pre-building static structures of said XML transaction (Paragraphs 
33-35); 

E) means for classifying dynamic structures of said XML transaction with empty 
tags and single occurrence classifiers for repeating dynamic structures 
(Paragraphs 34-35); 

I) wherein an occurrence of said runtime of said XML transaction occurs when 
said XML transaction occurs when said XML transaction is sent to a trading 
partner (Paragraphs 33-34, 36); 

J) wherein said combining comprises filling the empty tags of said dynamic 
structures (Paragraphs 34-35); and 

K) means for constructing a final XML structure based on the combining process 
(Paragraph 46); 

L) wherein said final XML structure comprises fully built dynamic structures that 
comprise completely filled tags (Paragraphs 34-35, 46). 

The examiner notes that Dan teaches "means for establishing an 
original pre-defined data type definition format for an XML transaction" as 

"According to the invention, a meta-contract governs or controls the negotiation 
process. The meta contract is either pre-negotiated or formed from information 
provided by the parties in one or more electronic documents, preferably in the 
form of profiles, described in greater detail below... Before creating a meta- 
contract, the parties must first accept a negotiation protocol to be used during the 
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negotiation process. After the parties accept the negotiation protocol, a meta- 
contract may be formed and the parties may begin a negotiation" (Paragraph 31), 
"FIG. 8 illustrates the preferred data type definition (DTD) covering all offer 
documents" (Paragraph 50), and "FIG. 9 illustrates the preferred data type 
definition (DTD) covering all counter offer documents" (Paragraph 58). The 
examiner further notes that Dan teaches "means for pre-building static 
structures of said XML transaction" as "The profile serves as the starting point 
of a negotiation by providing an initial version of a contract document" 
(Paragraph 33), "The profile may be expressed, for example, as an XML 
document whose contents may be incorporated into a contract" (Paragraph 34), 
and "One example of a contract template is an almost-complete electronic 
contract document with a few fields left blank" (Paragraph 34). The examiner 
further notes that Dan teaches "means for classifying dynamic structures of 
said XML transaction with empty tags and single occurrence classifiers for 
repeating dynamic structures" as "a negotiable field 1023 or 1024 may be 
treated as a blank that me be completed by the negotiating party" (Paragraph 
35). The examiner further notes that Dan teaches "wherein an occurrence of 
said runtime of said XML transaction occurs when said XML transaction 
occurs when said XML transaction is sent to a trading partner" as "The 
profile serves as the starting point of a negotiation by providing an initial version 
of a contract document" (Paragraph 33), "The profile may be expressed, for 
example, as an XML document whose contents may be incorporated into a 
contract" (Paragraph 34), and "One example of a contract template is an almost- 
complete electronic contract document with a few fields left blank" (Paragraph 
34). The examiner further wishes to state that the initial contract must combine 
the static fields (almost complete portions) and dynamic fields (the blank 
portions) at runtime (when the contract is sent to other party). The examiner 
further notes that Dan teaches "wherein said combining comprises filling the 
empty tags of said dynamic structures" as "a negotiable field 1023 or 1024 
may be treated as a blank that me be completed by the negotiating party" 
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(Paragraph 35) The examiner further notes that Dan teaches "means for 
constructing a final XML structure based on the combining process" as "the 
negotiation continues 370 to step 380 where the negotiation is complete and step 
390 leads to the service contract or TPA" (Paragraph 46). The examiner further 
notes that Dan teaches "wherein said final XML structure comprises fully 
built dynamic structures that comprise completely filled tags" as "the 
negotiation continues 370 to step 380 where the negotiation is complete and step 
390 leads to the service contract or TPA" (Paragraph 46). 

Dan does not explicitly teach: 
B) means for creating a copy of said original pre-defined data type definition 
format for said XML transaction; and 

M) wherein said final XML structure is validated by comparing said final XML 
structure against said copy of said original pre-defined data type definition format 
for said XML transaction. 

Thomas, however, teaches "means for creating a copy of said original 
pre-defined data type definition format for said XML transaction" as "the 
processor reads 12 the document type definition (DTD) of the first XML file and 
creates a copy 13 of the DTD" (Paragraph 38) and "wherein said final XML 
structure is validated by comparing said final XML structure against said 
copy of said original pre-defined data type definition format for said XML 
transaction" as "Once the user has finished entering modifications to the XML 
file and all of the modifications have been found to be either not significant or 
valid semantic changes, the temporary version of the XML file in the RAM 7 is 
written over the original XML file in the first storage region 4" (Paragraph 44). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of the cited references because 
teaching Thomas's would have allowed Dan's to provide a method to record 
changes to a markup language file by validating them in order to allow that file to 
be in compliance with constraints defined in a set of declarations, as noted by 
Thomas (Paragraph 5). 
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Dan and Thomas do not explicitly teach: 
D) wherein said static structures comprise a pre-built XML data structure with 
pre-filled values based on a transaction type and a predetermined trading partner 
profile; 

F) means for building a list of a sequence of said static and dynamic structures; 

G) means for linking said list to the type of XML transaction and said 
predetermined trading partner profile; 

H) means for combining said static structures with said dynamic structures at a 
runtime of said XML transaction based on said sequence, said type of XML 
transaction, said trading partner profile, and said dynamic structures of said XML 
transaction. 

Albazz, however, teaches "wherein said static structures comprise a 
pre-built XML data structure with pre-filled values based on a transaction 
type and a predetermined trading profile" as "the preferred embodiment of the 
invention provides for the creation of many different Ts&Cs Sets using the 
Business Rules Book. Each Ts&Cs Set represents an integrated set of terms and 
conditions which can be used selectively by the sales group to prepare and 
propose contracts to prospective buyer organizations. In a marketplace, different 
Ts&Cs Sets created by a supplier can be used by the e-commerce site to 
respond to a request for quotation (RFQ) from a buyer either by automatic rating 
and matching of the request or by pre-assigning a Ts&Cs Set to the buyer" 
(Paragraph 55) and "During the contract negotiation process the seller may 
decide to switch into a more attractive Ts&Cs Set, to overcome buyer reluctance 
or a competitive offer and win the buyer's business. This is readily done by 
simply referencing a different Ts&Cs Set identifier or reference number in the 
proposed contract or in response to an RFQ. Once a contract is approved and 
signed by the buyer, a copy of the selected Ts&Cs Set becomes an integral part 
of that contract. A contract may only include one Ts&Cs Set" (Paragraph 68), 
"means for building a list of a sequence of said static and dynamic 
structures" as "Product List Filter (PLF) is a representation of a seller's product 
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list which replaces the complete list of all products available from a seller 
organization (as used herein the term "products" includes both products and 
services). This representation comprises products selection and/or exclusion 
criteria, based on a selection metaphor. The representation criteria are structured 
and stored in a way that ensures rebuilding the targeted product list from a 
master product catalog, or from multiple catalogs or other product information 
sources, any time the target product list is required. Depending upon the used 
PLF, a generated list could be static with the same products being produced at 
every run, or could be dynamic with new products being added or removed 
according to changes taking place at the seller organization. FIG. 5 illustrates an 
example of the creation and storage of a Product List Filter" (Paragraph 76), 
"means for linking said list to the type of XML transaction and said 
predetermined trading partner profile" as "PLFs can be implemented within 
the contract preparation and negotiation cycles in different scenarios. For 
example, a seller may define a product list to be offered to a particular buyer and 
create a specific PLF for that list" (Paragraph 79), and "seller can define one or 
more PLFs that can be linked to offered Ts&Cs Sets or restricted to certain 
buyers, thus controlling the content of the product list on a buyer-specific basis. 
The specified buyer(s) become a target buyer for the filtered product list, and 
PLFs enforce the products viewable by any particular buyer in the execution 
aspect of the invention, discussed below, whenever the buyer accesses the 
seller's e-commerce site (store or marketplace). The buyer can then select or 
search for required products from the filtered version of the seller's master 
product list" (Paragraph 80), and "means for combining said static structures 
with said dynamic structures at a runtime of said XML transaction based on 
said sequence, said type of XML transaction, said trading partner profile, 
and said dynamic structures of said XML transaction" as "All contract Static 
Elements and Dynamic Elements are tied together in a contract profile, which 
includes linking the Product List Filter(s) and any Dynamic Elements in the Terms 
and Conditions Set. FIG. 6 illustrates an example of linking a Ts&Cs Page having 
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a multiple Folds to a multiple-tier PLF. Other scenarios might involve linking 
Ts&Cs Page Folds to other contract elements, for example to different divisions 
of a buyer organization" (Paragraph 81). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the teachings of the cited references because 
teaching Albazz's would have allowed Dan's and Thomas's to provide a 
method to increase the flexibility of contract negotiation through the removal of 
rigid pre-defined terms and subsequent replacement of dynamic best-fit terms, as 
noted by Albazz (Paragraph 12). 

Regarding claim 22, Dan teaches a computer system comprising: 

A) means for predefining said trading partner profile associated with a 
predetermined trading entity (Paragraph 38); 

B) means for filling said empty tags of said dynamic structures with business 
data values(Paragraphs 34-35); and 

C) building multiple repeating dynamic structures at runtime of said XML 
transaction (Paragraphs 34-35, 44); 

D) means for linking said static structures to a type of XML transaction and said 
predetermined trading partner profile (Paragraphs 5, and 32-34); and 

E) means for storing the linked static structures (Paragraph 37). 

The examiner notes that Dan teaches "means for predefining said 
trading partner profile associated with a predetermined trading entity" as 
"when each of the parties has a preexisting profile, an initial version of a contract 
may be created by automatically combining information from the profiles, subject 
to a later negotiation process" (Paragraph 38), "means for filling said empty 
tags of said dynamic structures with business data values" as "a negotiable 
field 1023 or 1024 may be treated as a blank that may be completed by the 
negotiating party" (Paragraph 35), "building multiple repeating dynamic 
structures at runtime of said XML transaction" as "A negotiation comprises 
one or more sub negotiations. Each sub negotiation involves a subset of all of 
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the items to be negotiated" (Paragraph 44), "means for constructing a final 
XML structure using said means for combining" as "the negotiation continues 
370 to step 380 where the negotiation is complete and step 390 leads to the 
service contract or TPA" (Paragraph 46), "means for linking said static 
structures to a type of XML transaction and said predetermined trading 
partner profile" as "The general information about the TPA provides the TPA 
name, its type and its version. The roles and the participants section specifies the 
various roles and participants along with the contact information of the business 
partners, and it also includes the valid duration of the contract, the number of 
times the contract may be used and how often it may be invoked" (Paragraph 5) 
and "Starting definitions and values for these types of information in the 
negotiated contract may be provided in a TPA template or party profile" 
(Paragraph 32), and "means for storing the linked static structures" as "In a 
preferred embodiment of the invention, an initial version of a contract may be 
obtained from a repository that contains a collection of searchable information, 
including individual businesses' contract templates or profiles and other related 
information" (Paragraph 37). 

Regarding claim 23, Dan further teaches a computer system comprising: 
A) wherein said static structures are pre-built prior to runtime of said XML 
transaction (Paragraphs 33-34). 

The examiner notes that Dan teaches "wherein said static structures 
are pre-built prior to runtime of said XML transaction" as "The profile serves 
as the starting point of a negotiation by providing an initial version of a contract 
document" (Paragraph 33), "The profile may be expressed, for example, as an 
XML document whose contents may be incorporated into a contract" (Paragraph 
34), and "One example of a contract template is an almost-complete electronic 
contract document with a few fields left blank" (Paragraph 34). The examiner 
further notes that contract of Dan's runs once the negotiation phase begins to fill 
in the initial blank negotiable fields 1 023 and 1 024. 
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Regarding claim 24, Dan further teaches a computer system comprising: 
A) wherein said pre-building of said static structures and said dynamic structures 
are pre-built at a time of installation of said trading partner profile in a database of 
said computer system (Paragraph 10). 

The examiner notes that Dan teaches "wherein said pre-building of 
said static structures and said dynamic structures are pre-built at a time of 
installation of said trading partner profile in a database of said computer 
system" as "providing a starting state for a contract, wherein the starting state 
may be a previous contract, a publicly defined template such as, for example, 
Open Buying on the Internet (OBI), or a template defined prior to the negotiation 
by one of the parties" (Paragraph 10). 

(10) Response to Argument 
A. Claims 1-6, 8-16, and 18-24 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Dan et al. (U.S. PGPUB 2002/0178103), in view of Thomas 
(U.S. PGPUB 2003/01 67446), and in view of Albazz et al. (U.S. PGPUB 
2002/0042757). 

Arguments (1): Regarding Independent Claims 1,11, and 21 , 
Appellant argues that "The present invention defines a "static structure" as "a 
pre-built XML structure with pre-filled values based on associated transaction 
type and TPP [Trading Partner Profile]", (Specification, paragraph [0024], lines 
13-15). Therefore, the pre-built XML "static structures" of the present invention 
are static, i.e., unchanging, and pre-filled with values based on the associated 
transaction type and trading partner profile. Hence, there are no negotiable fields 
in the static structures with pre-filled values of the present invention because the 
structures are static and pre-filled. In contrast, the contract template of Dan 
contains one or more negotiable fields 1023, 1024 that will be filled with future 
negotiations". 

However, the examiner wishes to states that Dan is merely used to teach 
the limitation "pre-building static structures of said XML transaction" in the 
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independent claims, and that the secondary art of Albazz is used to teach the 
limitation "wherein said static structures comprise a pre-built XML data structure 
with pre-filled values based on a transaction type". Moreover, the examiner 
wishes to refer to paragraphs 33 and 34 of Dan which state "The profile serves 
as the starting point of a negotiation by providing an initial version of a contract 
document" (Paragraph 33), "The profile may be expressed, for example, as an 
XML document whose contents may be incorporated into a contract" (Paragraph 
34), and "One example of a contract template is an almost-complete electronic 
contract document with a few fields left blank" (Paragraph 34). The examiner 
further wishes to state that Dan clearly teaches the claimed "pre-building static 
structures of said XML transactions" because the "almost-contract electronic 
contract document" template of Dan has elements that are already complete 
(static elements). 

Furthermore, the limitation of "wherein said static structures comprise a 
pre-built XML data structure with pre-filled values based on a transaction type" is 
considered as non-functional descriptive material. Specifically, the phrase 
"based on a transaction type" is deemed as non-functional descriptive material, 
and as a result, has no patentable weight. 

Arguments (2): Regarding Independent Claims 1,11, and 21 , 
Appellant argues that "However, the DTD of the present invention is originally 
fixed and its DTD copied, and does not require slight modifications or amending 
of element type declarations as does Thomas because the final XML structure of 
the present invention comprises pre-filled static structures, to which no 
modifications or amendments of the DTD are made, and dynamic structures that 
comprise empty tags, to which no modifications or amendments of the DTD are 
made, so that the final or constructed XML structure may be compared to or 
validated against the original pre-defined data type definition". 

However, in response to applicant's argument that the references fail to 
show certain features of applicant's invention, it is noted that the features upon 
which applicant relies (i.e., "[The DTD] does not require slight modifications or 
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amending of element type declarations") are not recited in the rejected claim(s). 
Although the claims are interpreted in light of the specification, limitations from 
the specification are not read into the claims. See In re Van Geuns, 988 
F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

Arguments (3): Regarding Independent Claims 1,11, and 21 , 
Appellant argues that "Albazz merely discloses generating a list that could be 
static with the same products being produced at every run, or could be dynamic 
with new products being added or removed according to changes taking place at 
the seller organization. In contrast, the present invention describes the feature of 
"building a list of a sequence of said static and dynamic structures", wherein both 
static and dynamic structures are previously defined, i.e., "pre-building static 
structures of said XML transaction, wherein said static structures comprise a pre- 
built XML data structure with pre-filled values based on a transaction type of said 
XML transaction and a predetermined trading partner profile; classifying dynamic 
structures of said XML transaction with empty tags and single occurrence 
classifiers for repeating dynamic structures".". 

However, the cited art of Dan is used to teach "pre-building static 
structures of said XML transaction" and "classifying dynamic structures of said 
XML transaction with empty tags and single occurrence classifiers for repeating 
dynamic structures". Moreover, the independent claim merely recites the 
limitation as "building a list of a sequence of said static and dynamic structures". 
Furthermore, the examiner wishes to refer to Paragraph 76 of Albazz which 
states that "Product List Filter (PLF) is a representation of a seller's product list 
which replaces the complete list of all products available from a seller 
organization (as used herein the term "products" includes both products and 
services). This representation comprises products selection and/or exclusion 
criteria, based on a selection metaphor. The representation criteria are structured 
and stored in a way that ensures rebuilding the targeted product list from a 
master product catalog, or from multiple catalogs or other product information 
sources, any time the target product list is required. Depending upon the used 
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PLF, a generated list could be static with the same products being produced at 
every run, or could be dynamic with new products being added or removed 
according to changes taking place at the seller organization. FIG. 5 illustrates an 
example of the creation and storage of a Product List Filter" (Paragraph 76). The 
examiner further wishes to state that by adding new products to a static list ("new 
products being added"), Albazz's list is both static (containing the previous list) 
and dynamic (the added products), rather than either static or dynamic. 

In addition, Appellant argues that "The static and dynamic product lists of 
Albazz do not disclose, teach or suggest the present invention's features of 
"wherein said static structures comprise a pre-built XML data structure with pre- 
filled values based on a transaction type of said XML transaction and a 
predetermined trading partner profile" or "dynamic structures of said XML 
transaction with empty tags and single occurrence classifiers for repeating 
dynamic structures". 

However, the cited art of Dan is used to teach the limitation of "dynamic 
structures of said XML transaction with empty tags and single occurrence 
classifiers for repeating dynamic structures". Furthermore, the examiner wishes 
to refer to Paragraphs 55, 68, and 79-80 of Albazz which state that "the preferred 
embodiment of the invention provides for the creation of many different Ts&Cs 
Sets using the Business Rules Book. Each Ts&Cs Set represents an integrated 
set of terms and conditions which can be used selectively by the sales group to 
prepare and propose contracts to prospective buyer organizations. In a 
marketplace, different Ts&Cs Sets created by a supplier can be used by the e- 
commerce site to respond to a request for quotation (RFQ) from a buyer either by 
automatic rating and matching of the request or by pre-assigning a Ts&Cs Set to 
the buyer" (Paragraph 55), "During the contract negotiation process the seller 
may decide to switch into a more attractive Ts&Cs Set, to overcome buyer 
reluctance or a competitive offer and win the buyer's business. This is readily 
done by simply referencing a different Ts&Cs Set identifier or reference number 
in the proposed contract or in response to an RFQ. Once a contract is approved 
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and signed by the buyer, a copy of the selected Ts&Cs Set becomes an integral 
part of that contract. A contract may only include one Ts&Cs Set" (Paragraph 
68), "PLFs can be implemented within the contract preparation and negotiation 
cycles in different scenarios. For example, a seller may define a product list to be 
offered to a particular buyer and create a specific PLF for that list" (Paragraph 
79), and "seller can define one or more PLFs that can be linked to offered Ts&Cs 
Sets or restricted to certain buyers, thus controlling the content of the product list 
on a buyer-specific basis. The specified buyer(s) become a target buyer for the 
filtered product list, and PLFs enforce the products viewable by any particular 
buyer in the execution aspect of the invention, discussed below, whenever the 
buyer accesses the seller's e-commerce site (store or marketplace). The buyer 
can then select or search for required products from the filtered version of the 
seller's master product list" (Paragraph 80). The examiner further wishes to state 
that Albazz clearly teaches an XML data structure (Ts&C Set) with pre-filled 
values (selecting amongst different pre-determined Ts&Cs Sets) that can be 
differentiating with respect to different profiles ("seller can define one or more 
PLFs that can be linked to offered Ts&Cs Sets or restricted to certain buyers, 
thus controlling the content of the product list on a buyer-specific basis. The 
specified buyer(s) become a target buyer for the filtered product list"). 

In addition, Appellant argues that "The static and dynamic product lists of 
Albazz are not explicitly defined as XML data structures corresponding to a 
transaction. A list is not a transaction. Therefore, Applicants respectfully submit 
that Albazz does not disclose, teach or suggest the present invention's feature of 
"pre-building static structures of said XML transaction, wherein said static 
structures comprise a pre-built XML data structure with pre-filled values based on 
a transaction type of said XML transaction and a predetermined trading partner 
profile; classifying dynamic structures of said XML transaction with empty tags 
and single occurrence classifiers for repeating dynamic structures; building a list 
of a sequence of said static and dynamic structures", as recited in independent 
claims 1,11, and 21". 
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However, the cited art of Dan is used to teach "pre-building static 
structures of said XML transaction" and "classifying dynamic structures of said 
XML transaction with empty tags and single occurrence classifiers for repeating 
dynamic structures". Moreover, the independent claim merely recites the 
limitation as "building a list of a sequence of said static and dynamic structures". 
Moreover, the examiner wishes to refer to Paragraphs 55, 79, and 80-81 of 
Albazz which state that the preferred embodiment of the invention provides for 
the creation of many different Ts&Cs Sets using the Business Rules Book. Each 
Ts&Cs Set represents an integrated set of terms and conditions which can be 
used selectively by the sales group to prepare and propose contracts to 
prospective buyer organizations. In a marketplace, different Ts&Cs Sets created 
by a supplier can be used by the e-commerce site to respond to a request for 
quotation (RFQ) from a buyer either by automatic rating and matching of the 
request or by pre-assigning a Ts&Cs Set to the buyer" (Paragraph 55), "During 
the contract negotiation process the seller may decide to switch into a more 
attractive Ts&Cs Set, to overcome buyer reluctance or a competitive offer and 
win the buyer's business. This is readily done by simply referencing a different 
Ts&Cs Set identifier or reference number in the proposed contract or in response 
to an RFQ. Once a contract is approved and signed by the buyer, a copy of the 
selected Ts&Cs Set becomes an integral part of that contract. A contract may 
only include one Ts&Cs Set" (Paragraph 68), "PLFs can be implemented within 
the contract preparation and negotiation cycles in different scenarios. For 
example, a seller may define a product list to be offered to a particular buyer and 
create a specific PLF for that list" (Paragraph 79), and "A seller can define one or 
more PLFs that can be linked to offered Ts&Cs Sets or restricted to certain 
buyers, thus controlling the content of the product list on a buyer-specific basis. 
The specified buyer(s) become a target buyer for the filtered product list, and 
PLFs enforce the products viewable by any particular buyer in the execution 
aspect of the invention, discussed below, whenever the buyer accesses the 
seller's e-commerce site (store or marketplace). The buyer can then select or 



Application/Control Number: 10/709,793 
Art Unit: 2168 



Page 



search for required products from the filtered version of the seller's master 
product list. All contract Static Elements and Dynamic Elements are tied together 
in a contract profile, which includes linking the Product List Filter(s) and any 
Dynamic Elements in the Terms and Conditions Set. FIG. 6 illustrates an 
example of linking a Ts&Cs Page having a multiple Folds to a multiple-tier PLF. 
Other scenarios might involve linking Ts&Cs Page Folds to other contract 
elements, for example to different divisions of a buyer organization" (Paragraphs 
80-81 ). The examiner further wishes to state that the product lists of Albazz 
clearly linked to the Ts&C Sets with represent the transaction. 

Arguments (4): Regarding Independent Claims 1,11, and 21 , 
Appellant argues that "Applicants respectfully submit that Albazz does not cure 
the deficiencies of Dan and Thomas, because Albazz also does not disclose, 
teach or suggest the present invention's feature of "pre-building static structures 
of said XML transaction, wherein said static structures comprise a pre-built XML 
data structure with pre-filled values based on a transaction type of said XML 
transaction and a predetermined trading partner profile". Instead, merely 
discloses generating a list that could be static with the same products being 
produced at every run, or could be dynamic with new products being added or 
removed according to changes taking place at the seller organization. ". 

However, the cited art of Dan is used to teach the limitation of "pre- 
building static structures of said XML transaction". Furthermore, the examiner 
wishes to refer to Paragraph 76 of Albazz which states that "Product List Filter 
(PLF) is a representation of a seller's product list which replaces the complete list 
of all products available from a seller organization (as used herein the term 
"products" includes both products and services). This representation comprises 
products selection and/or exclusion criteria, based on a selection metaphor. The 
representation criteria are structured and stored in a way that ensures rebuilding 
the targeted product list from a master product catalog, or from multiple catalogs 
or other product information sources, any time the target product list is required. 
Depending upon the used PLF, a generated list could be static with the same 
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products being produced at every run, or could be dynamic with new products 
being added or removed according to changes taking place at the seller 
organization. FIG. 5 illustrates an example of the creation and storage of a 
Product List Filter" (Paragraph 76). The examiner further wishes to state that by 
adding new products to a static list ("new products being added"), Albazz's list is 
both static (containing the previous list) and dynamic (the added products), rather 
than either static or dynamic. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner 
in the Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be 
sustained. 
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